Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Writing code for a custom super procedure

The nature of the super procedure also creates a programming challenge. Because the base procedure object and the super procedure are separately compiled objects, with their own name spaces, you cannot simply refer to frames in the base object. References to fields, variables, buffers, and other constructs are not automatically available to the super procedure, so the code that references them must change, and in general becomes somewhat more complex.

The Progress Version 9 ADM solves this problem for the SmartObjects themselves by defining a set of properties for each SmartObject type, whose values are stored in a temp-table record within the scope of the object. The {get} and {set} include files and the get<property> and set<property> functions provide access to those property values from other procedures, including in particular the object’s super procedures.

In your application code, you need to do something similar to get access to the objects or widgets inside a viewer or browser.

Note: In the context of a Progress application, the term widget has a very specific meaning, namely, any basic 4GL object with its own object handle. Thus not only are fill-in fields and other visualizations of data fields widgets, but so are other types of controls such as buttons, as well as objects like rectangles that would never be thought of as controls.

You cannot simply refer to field names or button names from a super procedure attached to a Viewer or Browser. This section introduces a simple way to encapsulate that access in such a way that it can be used from any visual object’s super procedure, and so acts as an API for writing super procedure code. The complete API, which will be explained later in this chapter, will be a standard part of Version 2 of Progress Dynamics, to help standardize and simplify writing client-side code.

To illustrate the different ways that you can write super procedure logic, parts of the API are built up in the following steps:

Defining logic in a single custom super procedure
Creating a new super procedure